Slicing and Dicing the Available Disk
Simple physics
tells you that you’ll get improvements in performance as you add more
disks to an array. Because each drive’s read/write head can operate
simultaneously, you get a fairly linear improvement as drives are added.
NAS and SAN offer the advantage of dynamically increasing the size of a
volume without taking the volume offline. This allows for the addition
of even more spindles.
Although it’s possible
to later resize a volume from a NAS or SAN, you must be careful not to
oversubscribe the device. Devices that support snapshots of the data
reserve twice the volume size that they claim for capacity. So, to make
100GB available to a server, the NAS reserves 200GB on itself. This
ensures that it can complete all transactions. This function can be
disabled on most devices, but it is not recommended. This removes the
protection from oversubscription of the disks.
When provisioning disk space for an Exchange server, you should consider a few rules of thumb when optimizing performance.
In a perfect world, an
entire SAN or NAS would be dedicated to just the Exchange Server 2010
environment. This would reduce the possibility of contention with other
applications. If your budget doesn’t allow for this, be aware of what
applications are shared with your SAN or NAS.
If you can’t dedicate a SAN
or NAS to your Exchange Server environment, build your aggregate from
disks that are spread out across multiple shelves. This helps distribute
the load across multiple backplanes and results in fewer spikes in
performances.
Try
not to make LUNs larger than they need to be. For example, if you plan
to have four storage groups with 50GB of mail each, create four LUNs of
50GB each rather than a single LUN of 200GB. This enables you to
separate the LUNs across both controllers and improves the performance
of the system. The potential pitfall here is that you could run out of
drive letters because Exchange Server 2010 allows for up to 150
databases in the Enterprise Edition. To work around this, mount the LUNs
as mount points instead of drive letters. This can greatly simplify
expansions of Exchange Server 2010 servers as you can place a storage
group on a drive letter and then mount new LUNs as mount points for each
new database that you need to bring online. This is exceptionally
useful when using snapshot functions in NAS or SAN in which the database
has to be dismounted for an integrity check because this typically
occurs at the LUN level.
To mount a LUN as a mount point rather than a drive letter, perform the following steps:
1. | Right-click My Computer and choose Manage on the shortcut menu.
|
2. | Expand Storage and click Disk Management.
|
3. | Right-click the unpartitioned space and select New Partition on the shortcut menu.
|
4. | When the New Partition Wizard launches, click Next.
|
5. | From the Select Partition Type screen, select Primary Partition, and click Next.
|
6. | Choose the size of the partition desired, and click Next.
|
7. | Select Mount in the Following Empty NTFS folder, and click Browse.
|
8. | Select
the folder that will host the new mount point, and click OK. Ensure
that this folder is empty. Choose to create a new folder, if necessary.
Click Next.
|
9. | Choose to format the drive as NTFS. Label it to reflect the name of the data it will house. Click Next.
|
10. | After the drive is formatted, click Finish.
|
Note
When configuring LUNs for
a cluster, be sure to create them as basic disk in Windows; otherwise,
the cluster cannot recognize the disks as potential cluster resources.
Predicting Disk Performance with Exchange Server 2010
When planning the number
of disks to use for LUNs for various functions in Exchange Server 2010,
the question that invariably comes up is “How many spindles do I need
for good performance?” Although it is fairly straightforward to
determine the I/O needs for various functions in Exchange Server 2010,
it can be trickier to predict the effect that the disk configuration
will have on the system. One of the most common configurations is to
utilize RAID 5 to provide redundancy at the disk level. To understand
the impact of RAID 5, consider the following:
RAID-5 performance can be
approximated as %Reads * IOPS per disk * (disks-1)) + (%Writes * IOPS
per disk * ((disks-1) / 4)) = Total IOPS
Or for the more mathematically oriented:
Total IOPS = (R * I(d-1)) + (W * I((d-1) / 4))
where:
With typical IOPS performance per disk being:
140–150 Random IOPS from 15,000-RPM disks (@<20ms disk latency)
100–120 Random IOPS from 10,000-RPM disks (@<20ms disk latency)
75–100 Random IOPS from 7,200-RPM disks (@<20ms disk latency)
